Cream of the Crop 26/Cream of the Crop 26.iso/bbs/kdom221.zip/KDOC-TXT.ZIP/KCOORD.TXT

Text File | 1997-06-15 | 39KB | 781 lines

        ┌──────────────────────────────────────────────────────┐
        │                       KINGDOMS                       │
        ├──────────────────────────────────────────────────────┤
        │          NETWORK COORDINATOR DOCUMENTATION           │
        │                     Version 2.21                     │
        ├──────────────────────────────────────────────────────┤
        │                                                      │
        │  Programming & Design : Dave Chapman : The Web BBS   │
        │                                                      │
        │   Copyright c 1993, 94, 95, 96, 97 - Dave Chapman    │
        │                 All Rights Reserved                  │
        │                                                      │
        │       3:712/523@FidoNet  169:3005/2@BattleNet        │
        │                                                      │
        ├──────────────── [e-mail] ────────────────┤
        │                                                      │
        │              - Kingdoms Support Page -               │
        │        http://www1.tpgi.com.au/users/kingdoms        │
        │                                                      │
        └──────────────────────────────────────────────────────┘


                           TABLE OF CONTENTS
                           ─────────────────

SECTION 1 : COORDINATOR OVERVIEW

        1.1. Document Purpose
        1.2. So you want to be a Coordinator?
        1.3. Network Overview
                1.3.1. Technical
        1.4. Terms and Definitions
                1.4.1. The Index
                1.4.2. Routing Rules
                1.4.3. Default Outbound
                1.4.4. Network Id

SECTION 2.0. UP & RUNNING

        2.1. Overview
        2.2. Choosing a Network ID
        2.3. Creating An Index
        2.4. Adding Nodes
        2.5. Modifying Nodes
        2.6. Deleting Nodes
        2.7. Reactivating Nodes
        2.8. Index File Dump
        2.9. Resetting the Game
                2.9.1. Overview
                2.9.2. Issuing a Reset
                        2.9.2.1. Resetting a Realm
                        2.9.2.2. Resetting a League
                2.9.3. How It's Done
        2.10. Coordinator Log
        2.11. Link Diagram
        2.12. Net Connections

SECTION 3.0. TRACKING PROBLEMS

APPENDIX A : NEW NODE APPLICATION


Section 1 : Coordinator Overview

1.1. Document Purpose

This document explains what it is to be a Kingdoms Coordinator (known as
a League Coordinator, or LC) and what tasks a LC does. If you're not a
Coordinator and are not thinking of becoming one, then there's no need
for you to read this to run Kingdoms on your BBS.

1.2. So you want to be a Coordinator?

A Coordinator is the person who manages a Kingdoms network. Kingdoms
makes this task pretty easy by automating all network management
functions, but there's still a lot to do just keeping track of new
applications on your network and managing problems that will arise time
to time. The Coordinator carries out the following tasks on a Kingdoms
network.

* Creates and maintains the Index, which is a list of all nodes in the
  League.
* Accepts new applications for BBS's that want to join the network.
* Issues game resets when required/desired.
* Is responsible for monitoring and correcting mail problems in the
  network, via the Coordinator maintenance options.
* Delete old or inactive nodes on the network.
* Generally keep things flowing as they should!

That's only an overview, but you get the picture! If you think you want
to get into all this and get a good network going, then read on!

1.3. Network Overview

1.3.1. Technical

A Kingdoms Network consists of a series of BBS's running Kingdoms and
communicating with each other via standard Netmail conventions. Each BBS
in the Network is known as a Realm. Kingdoms directly supports and can
address up to 35,000 Realms connected in one distinct network. In each
network there is ONE Coordinator node. All other nodes are equal in this
respect. Limited network diagnostic utilities (Worms and Routing
Reports) are available to a standard Kingdoms node, but only the
Coordinator node can issue the advanced network management commands to
directly affect the network as a whole, such as adding, deleting or
modifying individual nodes.

Each Realm in the Network must have configured an external mailer to
which Kingdoms can define file- attached netmail messages in the .MSG
format, such as FrontDoor or Blinkey supports. A switch is available
also in the outbound manager to support the Blinkey/Squish mailer file
attach message format. Obviously, a new Realm coming into the game must
have a link to another Realm for mail transfer and a valid network
address through which their respective mailers can communicate. Unlike
many other InterBBS games, it is quite permissable for each node in a
Kingdoms network to be on a different network. Eg, one Realm can use a
Fidonet address like 3:712/523 and the next an AdultLink address,
69:1171/200. As long as the mailers communicate, it doesn't matter to
Kingdoms what network it's creating outbound and processing inbound
files for. It will manage each seamlessley.

Note that the Coordinator node need not be central in terms of a network
`picture' in any way. As far as connections are concerned, it matters
only that the Coordinator, through some path, is connected to all other
nodes. The Coordinator Realm may be a central mail hub, or a node way
down a mail feed line.

1.4. Terms and Definitions

To get the most out of this document and run your network at it's best,
you'll need to understand the following terms :

1.4.1. The Index

Each BBS in your network must have an Index file, called KIDX.DAT. It
must reside in the `Game Directory', as defined in the Kingdoms Manager
for each BBS. If an Index is not found or it is empty, Kingdoms will
refuse to enter the InterBBS options for players. The Index is
effectively the `nodelist' for your network and is created and updated
by you, the Kingdoms coordinator. The Index has one record for each BBS
and holds (or is updated with) the following information.

1.      The Game name of each BBS in the network
2.    The Game name of the Sysop running each BBS
3.    The actual BBS address (Zone, Net, Node. Points are not supported)
4.    The BBS type, Normal, Default or Routed
5.    A counter for incrementing outbound file names for that BBS
6.    Most recent Recon date
7.    Mail type, Hold or Direct, Crash or No-Crash
8.    Time statistics, to and from, for each BBS
9.    Status : Active, Inactive, Pending or Deleted
10.     Default Connection Zone, Net, Node

I will discuss fully what these things mean later, but for now just be
aware that the Index exists and that it is used to define to each system
what BBS's are in the network and who routes data to whom.

1.4.2. Routing Rules

Routing Rules are rules specified by each Sysop for their BBS. They tell
Kingdoms where to send mail to for each node.

1.4.3. Default Outbound

When each Sysop in the network defines their node to the Index during
setup, a Default Outbound is assigned based on the network connections
you have defined which are held in each Index on each Realm. Relative to
each node, Kingdoms will set the Default Outbound as the outbound which
is the shortest (or only) available uplink to you, the Coordinator node.
The Self Correction facilities in Kingdoms 2.15 and later will poll the
Default Outbound at intervals specified by each Sysop in the `Other'
section of the Manager. This ensures the integrity of the network is
maintained by propogating changes that might have been missed through
the normal update channels when you actually make changes to the
network.

1.4.4. Network Id

Each Kingdoms network must have a unique Id. This is a two character
code that is used to ensure that the inbound files that Kingdoms
processes actually belong to the Leagu they're in. It also allows an
individual BBS to play in two (or more) different Kingdoms networks (ie,
run two separate Kingdoms games in different Leagues) without each
getting confused about which mail to direct to which game on their BBS.
Please note that though any combination of letters and numbers (not
special characters) may be used in the Net Id for your League, it is not
case sensitive. Thus, Kingdoms will consider Net Id "1a" as being the
same league as Net Id "1A'.

SECTION 2.0. Up & Running

2.1. Overview

Following are the basics of what a Coordinator needs to do to get a
network up and running and to maintain it. The remainder of the document
goes into detail about what each of these things mean if you want
further information. Everything done here is achieved using the general
and Coordinator functions in the Kingdoms Manager :

- Select a unique Network ID for your network.
- Define your own node using Generate Index.
- Add Pending nodes (nodes coming online soon)
- Generate Indexes for the Pending Nodes (so they can set themselves up)
- Release Pending nodes (make them active across the network)
- Modify node details (as required)
- Deactivate nodes for whatever reason when required.
- Reset the game network wide when needed.
- Check problems using Routing reports and Worms.

You may want to wing it from here, but I suggest reading the rest if you
REALLY want to understand what you're doing as a Kingdoms Coordinator.

2.2. Choosing a Network ID

In the Manager, you will have seen a place you can enter a `Network ID'.
If you are playing in an existing network, this is normally provided for
you. As a Coordinator however, you must select your own for your network
and make sure everyone in your network knows what it is and has entered
it correctly. If they have it wrong, Kingdoms on their system will not
process data from your network.

The Network ID is simply a means of tagging network mail as belonging to
your game (your network) rather than another. That way, data doesn't get
processed by nodes outside your network and/or using another Kingdoms
network as well as yours.

The NetID is used primarily in two places - KNetIn and KNetOut. The way
these are used will be explained shortly, but first it is advisable to
understand how file names are created by Kingdoms -

The format of a Kingdoms outbound file name is "KNxxxyyy.zza" where :

    KN     - A fixed prefix, standing for Kingdoms Network.
    xxx    - The BBS index number which created the file.
    yyy    - The BBS index number the file is destined for.
    zz    - The Network ID of the data in the file.
    a    - Check character to avoid duplicate filenames.

Thus, the file `KN003006.FAC' is a Kingdoms Network file going from BBS
3 and destined for BBS 6, ie, the 3rd and 6th BBS's listed in the Index
file. The file contains data for the Kingdoms network with ID `FA' and
has a unique identifier of `C'. The next outbound from BBS 3 would be
named `KN003006.FAD', & so on.

The 003 and 006 are really meaningless to Kingdoms itself as it does not
care who is sending data to whom as far as filenames go. This naming
convention has been chosen for Kingdoms Sysops to be able to see at a
glance what data is going where without having to edit files and search
out origin addresses, destination addresses, etc etc.

The part of the file name we want to talk about here however is the
Network ID. As discussed, it is part of the filename of outbounds
created by any Kingdoms system. When you choose the ID for your network,
you must NOT choose one that has special characters in it, or other
characters that are not valid characters in a DOS file name. To be
completely safe, I recommend you stay with alphabetic characters and
numbers. Case is not sensitive thus `Aa', `aa' and `aA' are, to
Kingdoms, the same Network ID. In full, valid characters in a Network
ID's are the letters A through Z and numbers 0 through 9 inclusive and
the characters underscore, _, carat, ^, dollar, $, tilde, ~,
exclamation, !, number, #, percent, %, ampersand, &, hyphen, -, braces,
{}, parenthesis, (), at, @, apostrophe, `, and grave accent, `.  No
other special characters are acceptable and your Network ID ***MUST
NOT*** contain spaces, commas, backslashes, periods or question marks.

To summarise all that, the network ID is used to generate outbound file
names. It must therefore be made up of characters which are valid in a
DOS filename. It must also be exactly two characters in length. As
discussed, the network ID should be unique. This is to stop mail from
your network getting muddled with mail that should be for another
network. How you make it unique is a harder question when you can't know
what everyone else is using, but I suggest you check with those nodes
that are in and/or joining your network. As long as they aren't using
the one you want already for another network, you're probably OK. A
complete list of all the NetId's I hear about/know of is maintained on
the Kingdoms support page on the Net -
http://www1.tpgi.com.au/users/kingdoms.

A file is also available on my BBS for FREQ under the magic name
`KNETID' which lists all the currently used Network ID's that I've been
told about. I urge you to FREQ a copy of this or check out the Web site
and choose a Network ID not already in use elsewhere in the world. That
done, then mail me (crash, net, internet, whatever) the one you've
chosen and I'll add it to KNETID so others can make sure they don't use
yours!

2.3. Creating An Index

This is where you'll first use your Coordinator options in the Manager.
As most people don't need to see them (in fact, only the Coordinator
can) they're not selectable by the normal arrow keys. To get to the
Coordinator options, you must specifically press Alt-C to bring up the
Coordinator menu. When selected, you'll have the following options
available :

        - Generate Index
        - Add a new node
        - Enable a new Node
        - Modify a node
        - Delete a node
        - Reactivate a Node
        - Index File Dump
        - Reset the Game
        - Cancel a Reset
        - Coordinator Log
        - Link Diagram
        - Net Connections

To make your Index, choose the first option, `Generate Index' by
pressing Enter when it is highlighted. It's assumed here that you do NOT
have an index (KIDX.DAT) file in your Kingdoms directory. If you do, you
must remove it before trying to create a brand new index. If one does
exist, the Generate Index option behaves differently and will offer you
the option of generating a Distribution index from the existing one the
Manager found. Generating a distribution index is discussed shortly
however - for now, we'll assume there is not one there.

After choosing Generate Index, a window will pop up asking you for your
node information. You're required to enter your network address, BBS
name and Sysop name. This data is needed and used to create the first
entry in your new index file. Your entry will also be tagged as the
Coordinator node. A couple of points to note here :

  * You MUST give your valid network address. When Kingdoms creates
  outbound packets from your BBS to others, this address is used as the
  originating address. If it's not valid, other nodes will proabably
  reject or misprocess your mail.

  * The BBS name and Sysop name you give here do NOT have to be the same
  as the ones you entered in the <O>ther submenu of the File drop down
  menu in the Manager. You can enter anything you like here. The names
  you enter here are the names seen by players in the game across the
  network. You are free to make them something more interesting (or
  obscure!) than your real BBS/Sysop name for the sake of interest in
  the game. This applies to the names of all systems in your League.

That's all there is to creating your Index File. Press Esc when you've
entered all the information correctly and confirm the data is correct.
Your new index file (KIDX.DAT) will be created with one Realm in it,
your own, tagged as the Coordinator Realm.

2.4. Adding Nodes

Once created you will, of course, want to add other nodes to it. Adding
nodes is a two step process. When you first add a new node, it does not
actually get activated or distributed immediately. Rather, it is placed
on your index only (not distributed across the network) as a PENDING
Node. The reason for this is to facilitate the creation of Distribution
Index files. I shall take a moment out to explain this. When a new Realm
(BBS) comes onto your network, that Realm will need an index file in
order to set themselves up. Of course, that index file must contain
their BBS, or they're not going to get far. Who wants a nodelist that
doesn't list their own node? You could just add the new node (without
having the `Pending' concept) and send them a copy of the Index from
your own system, but that will cause problems for two reasons :

1.      Firstly, your own Index probably already has your own routing
rules defined in it. If you give other nodes a copy of your own index,
the rules will be all wrong for them and it will be very confusing for a
new Kingdoms sysop!

2.      Also, if the node becomes active immediately rather than being a
Pending node, then players on your BBS, and others in the network when
the new node is distributed by Kingdoms, will doubtless start sending
recons to it and trying to communicate with the new node when it appears
on the Realms lists in the game itself. Most likely, that node is only
just setting itself up and is not ready to receive mail, if it's linked
to it's Kingdoms feed at all!

Instead of causing these problems, the PENDING node is created. In PEND
status, a Realm does not appear in your game Realm listings, nor is the
new node distributed to other Realms already active in your network. In
short, it doesn't exist yet to players in your game or to other Realms
at all, but it IS on YOUR, the Coordinator's, Index file. What you can
do at this point is use the `Generate Index' option again, as you did
when you first created the Index for your own Coordinator node. Because
an Index already exists this time, Kingdoms will assume that you do not
want to generate a completely new index. Instead, it will create for you
a Distribution Index file, which is a copy of your existing Index
including PENDING nodes, with all routing fields initialised to zero or
blanks, as appropriate. This you can send to your new nodes and they
will have a fully initialised, up-to-date Index, which DOES have their
node listed. They can set themselves up and when they're ready you can
Enable the Pending node, which will make that Realm active (listed and
usable by players in the game) on your Realm in addition to distributing
an Index update to all other Realms, making the new Realm active across
the net also without further action required on your behalf. The
Distribution Index file is created as KIDX.id, where nn is the Network
ID as defined in the <O>ther section of the Manager. It is not, of
course, called KIDX.DAT, as that would overwrite your existing Index
file!

So, to summarise the process of generating and Index and adding nodes to
your network:

* Create an new Index (using Generate Index) with your node information.
Obviously, this only ever needs to be done once!

* Add a node (using Add Node) which will be set to Pend status.

* Create a distribution index file for your new node(s) (using Generate
Index).

* Get the distribution index to the new node, or have them pick it up.

* When the new node is ready, release the Pending node to the network
(using Enable Node).


When you choose Add Node, you'll need to provide the following
information for each node you want to add :

* The new BBS address (Zone:Net/Node)
* The Game BBS Name
* The Game Sysop Name
* The `Connect To' site.

Items 1 thru 3 should be obvious, but item 4 requires some explanation.
The `Connect To' site is simply the BBS who the new BBS is going to pick
up mail from. As Coordinator you should have this information already as
anyone joining your network will need to have already decided a point
they'll pick up Kingdoms mail from and informed you where their pickup
is during their application.

As discussed, this info will be retained as a Pending node on your
Index. Other than choosing (and confirming) the Enable Node option from
your coordinator menu, there is NOTHING more you need to do to make the
new node active across your entire League. Once you Enable the node, the
following will take place, all internally & automatically through your
Kingdoms network.

1. An outbound record will be generated for each ACTIVE BBS in your
Index. When each outbound arrives at it's destination, each
destination's Index files will be updated automatically with the new
node during Kingdoms inbound processing. The routing rules defined for
new new node on each BBS are evaluated intelligently based on the
`Connect To' node you specified originally, ensuring mail is routed to
the new node properly by each BBS in the network. This information (and
any changes you make to it later) are saved in the Index on each Realm.
This data can be used later by the Sysop's to restore your `Default'
configuration should they need to do so. The Sysop on each of these
BBS's need not even know that a new node has been added, yet the game
will know of it, recognise it and route to it seamlessley. An entry will
also appear in the game news files informing players of the
arrival/existence of the new Realm.

2. Your local index file will be updated to reflect the change. Ie, the
Pending status on the node in your Index will be changed to Active.

A few safety nets and warning systems exist here for you :

1. If for some reason the `Connect To' node is not listed on a BBS's
index, the new node will have it's information routed to the Default
Outbound node, as defined for that BBS. While not as sure as a `Connect
To' node, it is a likely bet that this will adequately route the mail to
where it should be going.

2. As well as 1 above if the `Connect To' isn't found, a netmail message
is sent by Kingdoms back to you, the Coordinator, informing you of a
problem with that node. The problem is, of course, that they don't have
a node on their Index that should be there. In such cases, you may want
to get them to pick up another copy or your distribution Index or
distribute another node addition to make sure they're up- to-date in
case a previous addition got lost or misprocessed for some reason.

3. If the node already exists, the add will be aborted and a netmail
message returned to the Coordinator informing him or her of the
situation. This perhaps isn't a problem, but that is best determined by
yourself should you find it has happened.

2.5. Modifying Nodes

Modifying nodes is also a simple matter under Kingdoms.  For any node in
your Index, you can distribute changes to any node's Sysop Name, BBS
Name and/or address.

As you may be aware, a system's real Sysop & BBS names are used to match
up with Kingdoms registration numbers.  You may think therefore that you
shouldn't change a Sysop name & BBS name or a registered node will
suddenly find it's rego key no longer matches these fields. This is not
the case. What you are modifying if you do this are those names in the
INDEX file, not in the remote Realm's configuration file. Index file
searches are based on address only, not Sysop/BBS name, so anything
really can be placed in this field without affecting Kingdoms adversley.
For example, `Dave Chapman' on `The Web BBS' in the Web's configuration
could be called `Draken Noir' on `Dragons Lair' on the Index (and thus
have the Realm known as DragonsLair, network wide) without a problem.

These name fields can be changed as often and as much as you like, but
try to minimise use of the facility, particularly for the BBS name. It
can get confusing to players if a Realm they're used to seeing there
changes name all the time.

Changing the BBS Address is done in much the same way. You simply choose
the C>hange N>ode functions in the manager, then type in the modified
address.  When you confirm your changes, the modifications are
automatically distributed to the network for you. The address change on
all Realms, including your own, will automatically set up an Alias for
the old address on each node so mail in transit - even though it's
destination may be the old address when the change takes place on each
Realm - is smoothly routed to the correct (new) address.

2.6. Deleting Nodes

Similar to adding a new node, there are two steps to deleting a node on
your network. The first delete you issue for a particular node does not
actually delete the node. Instead, it marks it `Inactive'. This way you
can `turn someone off' without having to re-add them at a later stage
should you change your mind. The node will stay Inactive until another
Delete order is issued by the coordinator, or until it is returned to
normal operation, again by you, the LC. Of course, setting a node
Inactive will set it Inactive on ALL Realms, not just on your own.

If at some stage you decide you really do want to delete the node,
simply issue a second Delete Node request for that Realm. On all realms
in the network, the node will be irrevocably deleted. If you want to
bring it back at this stage, you will have to go through the Add Node
procedure.

A few notes on deleting a node :

* An Inactive node is simply ignored by Kingdoms completely for all
things. Maintenance will not request recons from it, Inbounds from it
(eg, Invasions) will be ignored and not processed, Players will not see
it and will not be able to select it for activity.

* It doesn't matter how long you leave an Inactive node inactive for. It
will stay in that status until you either issue another delete for it or
until you re-activate it.

* The options `Enable a new node' and `Reactivate a node' are different.
You `Enable' a Pending node to make it active. You `Reactivate' an
Inactive (deleted once) node to bring it back up on the Network.

2.7. Reactivating Nodes

It is quite possible that you've deleted a node for whatever reason and
find later (before you've issued another delete and removed it
permanently!) that you want to make it active again. This option will do
that for you. When selected, it will give you a list of all Realms in
your Index that are marked `Inactive'. Simply highlight the node you
want to reactivate and press Enter. Upon confirming this is what you
want to do, the node will be reactivated on your Index file, and an
instruction will be sent to all other nodes to do the same. Unless you
do something further to the node, it will again be an active Realm, just
like any other.

2.8. Index File Dump

This option is there simply so that, should you want to, you can get a
`raw' dump of your Index file. All info pertinent to each node is
provided nicely formatted and can be printed or used as you wish.
Obviously, this is a dump of the file only - changing data here will NOT
be reflected back in the real Index file in any way.

An example of an Index Dump for the Battlenet League (Netid 59) looks
like :

Kingdoms 2.19 Index File Dump for Net 59. 12-08-1996 (1996343) at 13:31:50.
====== ============== ============================== ================ =====
Record BBS Address    Realm Name                     Your Routing     Mail
       Node Status    Realm Sysop                    Last Recon
                                                     Network Connect
====== ============== ============================== ================ =====
     1 169:3800/5     RADAR'S wRECk ROOM             This Node        N/A
       Co-Ord         Radar                          No Recon
                                                     0:0/0
------ -------------- ------------------------------ ---------------- -----
     2 169:3800/1     MAX                            Default Outbound Hold
       Active         Peter Connerty                 No Recon
                                                     169:3800/5
------ -------------- ------------------------------ ---------------- -----
                          ... more nodes ...
------ -------------- ------------------------------ ---------------- -----
    20 169:3300/6     Enterprise BBS                 169:3800/1     N/A
       Active         Andrew Seeger                  No Recon
                                                     169:3300/1
------ -------------- ------------------------------ ---------------- -----

The fields for each Realm include :

* Record Number : The actual record number of the Realm on the Index File.
* Address       : The address of the Realm - Zone/Net:Node
* BBS Name      : The BBS Name shown on the Index to players
* Your Routing  : Where your node actually routes data to for the respective
                  Realm
* Mail Type     : Hold or Direct. Only applicable for outbound nodes
* Node Status   : Coord, Active, Inactive, Deleted, Pending.
* Sysop         : The Sysop Name shown on the Index to players
* Last Recon    : The date a Recon was last recieved from this Realm, or No
                  Recon.
* Connection    : Where the node is physically connected to on the network.

2.9. Resetting the Game

2.9.1. Overview

As you may be aware, any individual Sysop can reset their Kingdoms game
at any time by using the /RESET parameter on KMNT. As the Coordinator
Realm you can do this also, but you also have the power to issue a Reset
on a NETWORK WIDE basis. The reset can take place on a certain day
anywhere between five and 100 days (inclusive) in the future.

2.9.2. Issuing a Reset

When you choose the `rEset the Game' option, you will be asked if you
want to reset your entire League, or just a specific Realm.

2.9.2.1. Resetting a Realm
Resetting a Specifid Realm is a very powerful function and should be
used with caution. It is irreversable once issued, is immediate (when
the instruction reaches the Realm in question, it cannot be cancelled
and will happen as soon as Maintenance runs on that Realm) and cannot be
overridden using the /NORESET switch in KMNT by the remote Sysop.  I
don't think further explanation is necessary here - choosing this will
fully reset the Kingdoms game running on the Realm chosen once you
confirm and issue the instruction. As you may appreciate, this is a good
vehicle for bringing errant Sysops into line if all else fails. :-)

2.9.2.2. Resetting a League

Having selected a League reset, you will be asked the date you want a
reset to take place. Because this is such an important option, you must
give the date in very precise format - dd-mm/ccyy (day/month/century-
year), including zeros where appropriate. The first of March, 1996 then
would be entered as 01-03-1996. NO other format will be permissable and
the date entry routine checks for leap years as well to ensure no
invalid dates are accepted.

Having chosen a date, you will be asked if you want nodes to return a
message to you to acknowledge receipt of the reset instruction. It's a
good idea to do so as this will allow you to make sure everyone received
it properly, but you don't have to request receipts if you don't want
them. If you do, all nodes that receive the reset command and process
the instruction will send a message back to you which will appear in
your Coordinator's log (NOT in the game logs), telling you it was
accepted and confirming the appropriate date.

Lastly, the reset info will be redisplayed to ensure you have it right
and responding `yes' to the final confirm will issue the Reset
instruction network wide.

Two things will happen to let Kingdoms players on all realms know of the
impending League Reset. Firstly, a message will be placed in the game
news files when the reset command is received. On your local realm, of
course, this will appear in the news immediately. On each day when there
are five days or less remaining before the reset, another message will
appear in the `Todays News' file for the players stating it's due, and
how many days remain before the Reset takes place. This should give
players ample notice that it's coming!

2.9.3. How It's Done

As you may have gathered, KMNT is the vehicle by which a Reset is
achieved. When it runs, KMNT will always check for a pending reset (you
can always look yourself at F)ile->O)ther in the Manager for a reset
date if one is due) and when the day comes around, it will Reset the
game rather than running the normal maintenance process.

The process is fairly simple on the local Realm. The User file is
initialised, the message base trashed etc etc. All Outbound packets are
also deleted to get rid of network traffic belonging to the `old' game.
A few problems and issues are evident here however, which will now be
examined/explained :

* In a Leage Reset situation, Sysop's on individual boards may override
a Coordinator's Reset by using the /NORESET parameter in KMNT. Also, the
system may simply be down or have some error on the day the Reset is due
and for that reason it may simply not run. For this reason, KMNT will
continue to attempt to honor a Coordinator Reset indefinately each time
maintenance runs after the reset is due, if the reset has not already
been done. This should give ample time for those systems with problems
to correct them, run maintenance, and have the Reset processed as it
should be. In the case where a Sysop overrides the Reset, Kingdoms will
send a message back to the Coordinator (which will appear in the
Coordinator log) informing him or her of the situation. You may have
wanted that to happen, in which case you can deal with it as you see
fit. Otherwise, you can contact the Sysop directly to find out why this
has happened and to request them to remove the override. If they still
won't do it for some reason, it is perfectly within the Coordinator's
power to disable the Realm network wide as incencitve. A Sysop can't
override that command. :-)

* Due to time zone differences and such also, it is quite possible for
data to be floating around the network that is not removed during the
Reset. To solve this, no data will be accepted by inbound processing
excluding Recon and Network Timing requests/responses for 20 days after
the reset date on any Realm. Any such data will simply be deleted as it
arrives, thus clearing the network of old traffic.

2.10. Coordinator Log

This option gives you immediate access to your Coordinator Log. All
Coordinator Activity is recorded in this log and time stamped so you can
keep track of what changes you've made to the network and when. Because
you may want to keep this some time to maintain an historical record of
past events, maintenance will NEVER trim or roll over this log as it
does the newsfiles. You can, of course, delete it or rename it
(KCOORD.LOG) at any time if you wish - Kingdoms will just recreate it
when it needs to write something to it if it isn't already there.

2.11. Link Diagram

Particularly useful for the Coordinator, though it's also available to
Sysops on their Network menu as well, the Link Diagram creates a
`picture' of your network, based on the Default network links specified
in the Index. This is a very handy means of both seeing at a glance who
you have connected to who on the network and verifying all links are as
they should be. More information, as it pertains to the Sysop's point of
view, is available in the Manager documentation under the section titled
`Link Diagram' which may be of interest.

2.12. Net Connections

This option allows you to change the default connections of any node in
the network. This change is propogated to ALL Index files on all Realms
in your network of course, not just your own. While very simple to use,
it is an extremely powerful function as it is the crux of automating
network routing in Kingdoms. When you change a network connection
(simply by selecting the new node a realm connects to), the change data
will be propogated to all nodes in the network. Upon receipt of the
change, the inbound processor on each node will apply it and re-evaluate
ALL connections to optimize the routing definitions on the node and
bring into effect any changes required by the new connection rules.

SECTION 3.0. TRACKING PROBLEMS

To you, the Kingdoms Coordinator, it is particularly important that you
are able to track network problems. Realms may go offline for any number
of reasons that may not even be their own fault. For example, a Realm
feeding another Kingdoms data may simply set their routing incorrectly,
meaning that realm never gets its data. Both Worms and Routing Rules are
powerful options that can help you track these types of errors. They are
covered fully in the Sysop documentation, KSYSOP.DOC, so I won't talk
about them again here. Please refer to that document if you need to know
more about them.

Several Coordinators have asked me how to tell what node is running what
version of Kingdoms. FYI, as of version 2.19,  a Worm report returns
current Kingdoms version numbers for all Realms through which they pass.
Previously, this information was only available (and still is) by
sending a routing report specifically to the node you wanted to know
about.

Appendix A : New Node Application

You may use the form below as your formal `application' form for joining
your Kingdoms network. All people need to is fill it in then send it to
you. It contains all the information you need to add a BBS to your
Index.


       ----------------------------------------------------------

               Kingdoms Network Node Addition Application


BBS Name         : ____________________________________


Sysop Name        : ____________________________________


Address            : ________ : ________ / ________


Connect To         : ________ : ________ / ________


NetID (if known)        : __________

This form is used to gain access to a Kingdoms network. You should crash
it through to your Coordinator who will process your addition and see it
is added to all nodes in the index.

       ----------------------------------------------------------

                  - End of Coordinator Documentation -